This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 

BEST AVAILABLE IMAGES 



Defective images within this document are accurate representations of the 
original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 



BLACK BORDERS 

TEXT CUT OFF AT TOP, BOTTOM OR SIDES 
FADED TEXT 
ILLEGIBLE TEXT 
SKEWED/SLANTED IMAGES 
COLORED PHOTOS 

BLACK OR VERY BLACK AND WHITE DARK PHOTOS 
GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents >vi7/ not correct images, 
please do not report the images to the 
Image Problems Mailbox. 



THIS PA6E BIMK mm) 



(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 




(43) International Publication Date (10) International Publication Number 

19 April 2001(19.04^001) pCT WO 01/27723 Al 



(51) IntcmatioDal Patent Classification^: G06F 1/00. 
G07C9/D0 

(21) latenutional AppUcation Nnmbcn PCT/GB0aO3850 

(22) International FiUng Date: 6 October 2000 (06.10.2000) 

(25) Filing Language: English 

(2d) Pablicatioo Language: En^ish 

(30) Priority DaU: 

99238QL4 8 October 1999 (08.10.1999) GB 

(71) Applicant ffbr all designated Suaes except US): 
HEWLETT-PACKARD COMPANY [USAJS]; 3000 
Hanover Street. Palo Alto, CA 94304 (US). 

as (72) Inventors; and 

^ (7S> Inventors/Applicants (for US oniy): VAMVAKAS* 
Athanasios [GR/GR]; Maigaiition 69» Kanaateroi, Athens 



(GR). PEARSON, Siani [GB/GB]; 35 Sandyleaze, West- 
bury-on-Trynu Bristol BS9 3PZ (GB). CHEN, Uqaa 
[CN/GB]; 1 Harvest Qose, Bradley Stoke, Bristol BS32 
9DQ (GB). 

(74) Agent: LAWRENCE, Richard, Anthony; Hewlett 
Packard Limitrd, IntrTlpmial Propeny Section, Blton 
Road, Stoke Gi£f(mS, Bristol BS34 8(2Z (GB). 

(81) Designated SUtes (national): JP, US. 

(84) Designated States (regional): Eunqiean patent (AT, BE. 
CH, CY. DE, DK, ES, Ft FR, GB. GR, IE, IT. LU, MC 
NL, FT, SE). 

PnbUshed: 

— With international search report 

Far two'letter codes and other abbreviations^ refer to the "Guid' 
once Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regtdar issue cf the PCT Gazette. 



5 (54) Title: TRUSTED COMPUTING PLATFORM WITH BIOMETRIC AUTHENTlCAnC^ 




n 



O 



Transactions ba t w asn TC, SC and BR 

(57) Abstract: A method is provided for auteoticati&g a user by a miinmii>g platfdnn contain i ng a trasted component having a 
secure processor protected from physical and logical ittt afaeu oe. The method comprises the secure processor authenticating a bio- 

mgtrie mflfW; th^ »rm pnci^Knr ■ntfvTtt4«ting a «genre tntyn crwrtnwwiig ■nthwirig nger hiometrig data; captm of nser hkmiglric 

data by the toroetric reader, and tratafer of die captm e d ti^ 

biocoetric data to the secure processor; comparism of die antfaentic user biometric data with the caponed user biometric data; and 
authentication of the user by the secure p r o ce s&or oo the basis of the biometric data compajison. A data processing system for pro- 
viding such anthrmicatiwi (and each of the components of socfa a system: a computing platftHin, a biometTic reader, and a secure 
token, pitferahly a sman card) are also provided. 



wo 01/2T723 PCT/GBO0/03&5O 

1 

TRUSTED COMPUTTNO PLAITORM WTTH BIOMEHUC AUTHENTICAnON 



The invention provides a method for user authentication and a system, and 
components of a system, for providing such user authentication. 

5 

Security tokens, for example smart cards or cryptographic coprocessors, have been 
proposed for various security functions inchiding accessing computer platforms (liost 
platforms") and electronic commerce. For example, a smart card storing confidential 
information accessible only to a relevant user can be used by the user to log on to a 
10 computer, to sign a document, or to provide credentials needed for electronic 
commerce. Where a user needs to access sensitive information or services, biometrics 
can also be used to enhance user authentication. 



Authentication poses particularty difficult problems in distributed enviroimients, 
15 where a primaiy server may not be available and each individual host needs to be able 
to enforce access control decisions. It is important that a higih degree of security is 
maintained (particularly in military or financial systems) while the functionality of the 
system must be acceptable to users. If biometrics is used to enhance authentication, 
any personal biometric information should be properly secured against unauthorised 
20 access or manipulation. Furthermore, attacks such as spoofing of users, unauthorised 
modification of readers, substitution of software or replay attacks need to be 
prevented. 



All existing biometric systems use two procedures to verify users. One is ermslment - 
25 the system cq)turcs an individual's biometric information (referred to hereafter as 
*^iocode'*). The second is the matching process, by which the Bio code is cony ared 
to recently captured biometric information (hereafter referred to as the **Bio data") 
resulting in either a match, or no match. The matching process is further categorized 
into verification (one-to-one) or identification (one-to-many). Many different 
30 biometric systems exist (fingerprint, retina, hand geometry...) and the actual choice 
for a system mtegrator depends on the characteristics of each techruque (a signature 
may be excellent for finance but poor for access control...). 
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It is becoming common to implement biometric technology in existing systems to 
increase security and reduce the problems of password management. The biggest 
threat to such systems is that the user's biometric data becomes compromised, 
allowing replay attacks. Existing vendors claim to support encryption between 
5 biometric reader and computer, but this is generally at a low level and susceptible to 
replay. 

Existing protocols for secure authentication using biometric readers and smart cards 
are described in "Smart cards portable security" by J-P Thomasson and L Baldi, 
10 Second Annual IEEE International Conference on Innovative Systems in Silicon, 
1997, and in "On Enabling Secure Applications through Off-line Biometric 
Identification'* by GI Davida, Y Frankel and BJ Matt, Symposium on Security and 
Privacy TF FF 1998. h these arrangements, smart cards are used essentially for 
storage, and problems of eavesdropping on the biometric reader are not discussed. 

IS 

In a first aspect, the invention provides a conq)uting platfonn adq)ted to authenticate 
a user, comprising: a trusted component having a secure processor protected &om 
physical and logical interfemce; communication paths between the trusted 
conqKment and firstly, a biometric reader adq>ted to c^ture biometric data fit)m a 

20 user and having a read^ identifier and, secondly, a secure token for storing authentic 
biometric data of a user and having a token identifier; wherein the secure processor is 
adapted to authenticate ttie biometric leBdcr and the secure token by their respective 
identifiers, retrdve authentic biometric data finom Ae secure token, retreive captured 
biometric data firom the biometric reader, and compare the authentic biometric data 

25 and tiie captured biometric data to authenticate a user. 

In a second aspect, the invention provides a biometric reader ad^ted to cq>ture 
biometric data finom a user and conqmsing a reader identifier, wherein the biometric 
reader has a cryptographic identity and a cryptographic processor. 

30 

In a third aspect, tfie invention provides secure token for retaining authotic user 
biometric data, conqnising: a memory holding the authentic user biometric data; and a 
token identifier. 
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In a fourth aspect, the invention provides a data processing system comprising a 
computing platform, a biomethc reader, and a secure token as indicated above. 

5 In a fifth aspect, the invention provides a method of authenticating a user by a 
computing platform containing a trusted component having a secure processor 
protected from physical and logical interference, the method comprising: the secure 
processor authenticating a biometric reader, the secure processor authenticating a 
secure token containing authentic user biometric data; capture of user biometric data 

10 by the biometric reader, and transfer of the captured user biometric data to the secure 
processor, transfer of the authentic user biometric data to the secure processor, 
comparison of the authentic user biometric data with the captured user biometric data; 
and authentication of the user by the secure processor on die basis of the biometric 
data comparison* 

15 

Even though biometrics is an emerging technology with a promising future, most 
work done by the scientific community has concentrated on inq)rovement of biometric 
algorithms. The present inventors have realised that protection of biometric 
information for user authentication may be more significant In particular, it is 

20 particulariy desirable that systems which implement biometric technology \ise secure 
protocols for transmission of biometric infimnation, to prevent eavesdropping. 
Pre fe rred embodiments of the invation provide a secure protocol and enviromnent 
for transmission of biometric information, a secure environment and storage for Bio 
code and Bio data, and authentication and integrity checks between relevant 

25 conqxments. 

Of use in the present invention is a trusted component (described here below but also 
in ihc ^iicanf s copending Ihteraational Patent Application No. PCT/GB 00/00528 
entitled "Trusted Conqmting Platform", filed on 15 February 2000 and incorporated 
30 by reference herein). Sudi a conq>onent has the main purpose of reassuring a user or 
odier interacting party that a platform is reliable and is not at risk f subversion. 
Other desirable functionality includes monitoring of die integrity of code and of 
providing a secure, reliable display to the user. A trusted component desirably 
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contains a cryptographic processor and the capacity to communicate securely with 
other processing entities. 



A preferred embodiment of the present invention uses a tamper-proof trusted 
5 component (TC) in a computing platform (possibly public, or shared by several users) 
in conjuction with a secure token such as a smart card (SC) and a biometric reader 
(BR) (typically an indq)endent machii>e) to authenticate the owner of the token 
securely. If mutual authentication succeeds, biometric data is obtained via the reader 
and compared within the trusted component with bio code pre-stored in the secure 
10 token. 



In the preferred model the TC is the main controller of the information flow, acting 
like a primary server. The SC carries Bio code and transfers it securely to the TC. 
The BR should also obtain and send the Bio data to the TC securely. 

15 

In specific arrangements according to the invention, authentication is as follows. SC 
and TC mutually authenticate - if successful. Bio code passes to the TC. 
(AltCTatively Bio code could be held centrally under server control and accessed by a 
reference passed from the SC). The TC authenticates the BR (may not be necessary if 

20 the BR is integral with the TCs platform, or with the SC). The SC may also need to 
authenticate the BR (indirectly, via the TC). If authentication is satisfied, user data 
may be csptured by the BR and sent to the TC, which compares Bio code and Bio 
data. The matdi rtsuh can be rqxnted to the user by a trusted display (described 
below) or to the SC * rq>orting to die SC may be effective if certain data is only to be 

25 released by (he SC after user authentication. The TC may then be used to obtain 
documats restricted to the owna* of the SC. Eitfier or both the TC and the SC can 
make a log of successful or fidled autfamtication attentpts, transfer of Bio code or 
data, and/or the results of the matching process (togetha with any data or qiplications 
used in consequence). 

30 

In a prefened arrangement, SC authenticates the TC, TC authenticates the BR and tiie 
TC, and the SC and die TC work together to authenticate the user. The trusted 
relationships are as follows: SC, TC and BR kn w the public keys of a certificati n 
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authority (CA) and believe that only the CA knows the corresponding private keys 
and that these key pairs are valid. SC» TC and BR each believe that the ther entities 
will follow the correct protocol. 

5 Specific embodiments of the invention will now be described, by way of example, 
with reference to the accompanying drawings, in ^ch: 

Figure 1 shows elements of a host computer qjpropriate for use as a trusted client 
platfoms in embodiments of the invention; 

10 

Figure 2 shows the hardware architecture of the host computer of Figure 1; 

Figure 3 shows the elements of a trusted device suitable for use in embodiments of the 
invention; 

15 

Figure 4 shows a preferred process for obtaining an integrity metric; 

Figure 5 shows a process for verifying the integrity of a trusted platform; 

20 Figure 6 shows a process for verifying the integrity of a trusted platform by a user 
with a smart card^ 

Figure 7 shows the processing engine of a uso* smart card suitable for use in the 
process of Figure 6; 

25 

Figure 8 shows a physical system for implementing an embodiment of the invention; 

Figure 9 shows transactions between components in an embodiment of tiie invention; 
and 

30 

Figure 10 shows a logical arrangement f each component used in an embodiment of 
the inventioa 
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An embodiment of the present invention will now be described, by way of example. 
A part of the system of this preferred embodiment is a client platform will be 
described which contains a trusted component, the trusted component allowing secure 
and reliable interaction with the client platform by users or other parties 

5 communicating with the client platfonn. Such a trusted component is described 
below, but is more fully described in the applicant's copending International Patent 
Application No. PCT/GB 00/00528 entitled Trusted Computing Platform" filed on 
1 5 February 2000 and incorporated by reference herein. The tr\isted component in tiie 
client platform also controls the client platform display, so the user can be confident 

10 that what is seen on the display has not been subverted by an unauthorised process 
operating on the client platform. This aspect of the trusted component is also 
described below, but is more fiilly described in the applicant's copending International 
Patent Application No. PCT/GB 00/01996 entitled "System for Digitally Signing a 
Document** filed on 25 May 2000 and incorporated by reference herein. The system 

15 also employs in preferred embodiments a trusted token personal to a user * in the 
embodiment described in detail here, ttie trusted token is a uso* smart card. In 
addition, in the embodiment described, not only die client platform but also tiie server 
contains a trusted component (though this does need to have trusted display 
functionality). 

20 

Certain elements of the system - the trusted component, including trusted display 
functionality, and ttie user smart card - will now be described in detail with reference 
to Figures 1 to 7. The dolled person will appreciate that in the context of the present 
invention, the specific form of trusted computing platform (and trusted conqx>noit), 
25 trusted display and smart card are not critical, and may be modified without departing 
from Ae scope of tte invention as claimed. 

To adiieve a trusted conqauting platform, there is incorporated into the con^>uting 
platform a physical trusted device whose function is to bind the identity of the 
30 platform to reliably measured data that provides an integrity metric of the platform. 
The trusted device may also (as is described below) act as a trusted display processor 
The trusted display processor (or a device with sixrular properties) is associated with 
video data at a stage in die video processing beyond tiie point where data can be 
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manipulated by standard host computer software. This allows the trusted display 
processor to display data n a display surface without interference or subversion by 
the host computer software. Thus, the trusted display processor can be certain what 
image is currently being displayed to the user. The identity and the integrity metric 
5 arc compared with expected values provided by a trusted party (TP) that is prq}ared to 
vouch for the trustworthiness of the platform. If there is a match, the implication is 
that at least part of the platform is operating coirectly, dq)ending on the scope of the 
integrity metric. 

10 A user verifies the correct operation of the platform before exchanging other data with 
ttie platform. A user does this by requesting the tmsted device to provide its identity 
and an integrity metric. (Optionally the trusted device will refiisc to provide cvidmcc 
of identity if it itself was unable to verify correct operation of the platform.) The user 
receives the proof of identity and the identity metric, and compares them against 

15 values it believes to be true. Those proper values are provided by the TP or 
another entity that is trusted by the user. If data reported by ihc trusted device is the 
same as that provided by the TP, 4e user trusts the platform. This is because the user 
trusts the entity. The entity trusts the platform because it has previously validated the 
identity and determined the proper integrity metric of the platform. 

20 

Once a user has established trusted operation of the platform, he exchanges other data 
with the platfOTin. For a local usa; the exchange migjit be by interacting with some 
software application running on the platform. For a remote user, the exchange migjit 
involve a secure transaction. In eithw case, the data exchanged is 'signed' by the 
25 trusted device. The user can thm have greato* confidence that data is being 
exchanged with a platform ¥^se behaviour can be trusted. 

Hie trusted device uses cryptogFq>hic processes but does not necessarily provide an 
external inter&ce to tiiose cryptogrqihic processes. Also, a most desirable 
30 inqjlementation would be to make the trusted device tampcrproof, to protect secrets 
by making than inaccessible to oAer platform functions and provide an environment 
that is substantially immune t unauthorised modification- Since tamper-proofing is 
impossible, flie best approximation is a trusted device that is tamper-resistant, or 
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tamper-detecting. The trusted device, therefore, preferably consists of one physical 
component that is tan^)er-resistant 

Techniques relevant to tamper-resistance are well known to those skilled in the art of 
5 security. These techniques include methods for resisting tampering (such as 
appropriate encapsulation of the trtisted device), methods for detecting tampering 
(such as detection of out of specification voltages. X-rays, or loss of physical integrity 
in the trusted device casing), and methods for eliminating data when tampering is 
detected. Further discussion of ap propr iate techniques can be found at 
10 http://www.cl.cam.ac.uk/-mgk25/tamperJitml. It will be appreciated that, although 
tamper-proofing is a most desirable feature of the present mvoition, it does not enter 
into the normal operation of the invoition and, as such, is beyond the scope of the 
present invention and will not be described in any detail hoein. 

IS The trusted device is preferably a physical one because it must be difficult to forge. It 
is most preferably tampon-resistant because it must be hard to counterfeit It typically 
has an engine capable of using cryptogn^hic processes because it is required to prove 
identity, both locally and at a distance, and it contains at least one method of 
measuring some integrity metric of the platform with which it is associated. 

20 

Figure 1 illustrates a host conqrato* system in which the host computo' is (for 
example) a Personal Computer, PC, vMch operates under the Windows NT™ 
operating system* According to Figure 1, the host compute 100 is connected to a 
visual display unit (VDU) 105, a keyboard 110, a mouse US and a smartcard reader 

25 120, and a local area n^ork (LAN) 125, which in turn is connected to the bitonet 
130. Herein^ the smartcard reader is an indepmdeot unit, although it may be an 
integral part of the keyboard. The VDU, keyboard, mouse, and trusted switdi can be 
tfaou^ of as die human/computer inter&ce (HQ) of Ae host computer. More 
specifically, die display, when operating under trusted control, as will be described, 

30 can be thought of as part of a trusted user intofitce'. Figure 1 also illustrates a 
smartcard 122 for use in die presmt embodiment as will be described. 



Figure 2 shows a hardware ardutecture f the host computo' of Figure 1. 
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According to Figure 2, the host computer 100 comprises a central processing unit 
(CPU) 200, or main processor, connected to main memory, which comprises RAM 
205 and ROM 210, all of which are mounted on a motherboard 215 of the host 
5 computer 100. The CPU in this case is a Pentium™ processor. The CPU is connected 
via a PCI (Peripheral Component Interconnect) bridge 220 to a PCI bus 225, to which 
are attached the other main components of the host computer 100. The bus 225 
comprises ^jpropriate control, address and data portions, which will not be described 
in detail herein. For a detailed description of Pentium processors and Pd 
10 architectures, which is beyond the scope of the present description, the reader is 
referred to the book, *The Indispensable PC Hardware Handbook", 3rd Edition, by 
Hans-Peter Mcssmer, published by Addison-Wcsley, ISBN 0-201-40399-4. Of 
course, the present embodiment is in no way limited to implementation using Pentium 
processors, ^A%dows™ operating systems or PCI buses. 

15 

The other main components of the host computer 100 attached to the PCI bus 225 
include: a SCSI (small computer system inter£u:e) adaptor coimected via a SCSI bus 
235 to a hard disk drive 2600 and a CD-ROM drive 2605 ; a LAN (local area network) 
adaptor 250 for connecting the host computer 100 to a LAN 125, via which the host 

20 computer 100 can conmiunicate with other host computers (not shown), such as file 
servers, print servers or email servers* and the Internet 130; an 10 (ii^ut/output) 
device 225, for attaching the keyboard 110, mouse 115 and smartcard reader 120; and 
a trusted device 260 (which incorporates the trusted displ^ processor function). The 
trusted display processor handles all standard display functions plus a number of 

25 furtha* tasks, which wiU be described in detail below. ^Standard displi^ functions' are 
those functions that one would normally expect to find in any standard host computer 
100, for example a PC operating under the Windows NT™ operating system, for 
displaying an image associated with the operating system or s^lication software. 

30 All the main components, in particular the trusted device 260, are preferably also 
integrated onto the m therboard 215 of the host computer 100» although, SCTietimes, 
LAN adapters 250 and SCSI adi^ters 230 can be of the phigin type. 
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Typically, in a personal computer the BIOS program is located in a special reserved 
memory area 215, the upper 64K of the first megabyte of the system memory 
(addresses F000h to FFFFh), and the main processor is arranged to look at this 
memory location first, in accordance with an industry wide standard 

5 

The significant difference between the platform and a conventional platform is that, 
after reset, the main processor is initially controlled by the trusted device, which then 
hands control over to the platform-specific BIOS program, which in turn initialises all 
ii^ut/ou^ut devices as normal. After the BIOS program has executed, control is 
10 handed over as normal by the BIOS pr o gram to an operating system program, such as 
Windows NT (TM), which is typically loaded into main memory fiom a hard disk 
drive. 

Qearly, this change fiom the normal procedure requires a modification to the 
15 implementation of the industry standard, whereby tfie main processor 200 is directed 
to address the trusted component (also described as trusted device) 260 to receive its 
first instructions. This change ixuy be inade simply by hard-coding a different address 
into the main processor 200. Alternatively, the trusted device 260 may be assigned 
the standard BIOS pr ogr am address, in which case there is no need to modify the 
20 main processor configuration. 

It is highly desirable for the BIOS boot block to be contained within the trusted device 
260. This prevents subversion of the obtaining of the integrity metric (which could 
otherwise occur if rogue software processes are present) and prevents rogue software 
25 processes seating a situation in wfaidi the BIOS (even if correct) fails to build the 
proper environment fioT the operating system. 

Ahhougli, in the prefored form to be described, the trusted device 260 is a single, 
discrete conQ)onent, it is envisaged that the functions of the trusted device 260 may 
30 alternatively be split into multiple devices on the motherboard, or even integrated into 
one or more of the existing standard devices f the platform. For example, it is 
feasible to integrate one r more of the functions of the trusted device into the main 
processor itself provided that the functions and their communications caim t be 
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subverted. This, however, would probably require separate leads on the processor for 
sole iise by the trusted functions. Additionally or alternatively, althou^ in the present 
embodiment the trusted device is a hardware device that is adapted for integration into 
the motherboard 21 S, it is anticipated that a trusted device may be implemented as a 
5 'removable' device, such as a dongle, which could be attached to a platform when 
required. Whether the trusted device is integrated or removable is a matter of design 
choice. However, where the trusted device is separable, a mechanism for providing a 
logical binding between the trusted device and the platform should be present 

10 After system reset, the trusted device 260 performs a secure boot process to ensure 
that the operating system of the platform 100 (including the system clock and the 
display on the monitor) is running properly and in a secure manner. During the secure 
boot process, the trusted device 260 acquires an integrity metric of the computing 
platfom 100. The trusted device 260 can also perform secure data transfer and, for 

15 example, authentication between it and a smart card via enayption/deayption and 
signatureAreiification. The trusted device 260 can also securely oiforce various 
security control policies, such as locking of the user interfiice. Moreovo; in this 
aiiangement the trusted device 260 also acts as a trusted display processor, providing 
the standard display functions of a di^lay processor and the extra, non-standard 

20 functions for providing a trusted user inter&ce. 

According to Figure 3, die trusted device 260 comprises: 
a controller 300; 

non-volatile monory 305, for example flash memory, containing respective 
25 control pi ogi am instructions (i.e. fiimware) for controlling the operation of the 
microcontrolla 300 (alternatively, the trusted device 260 could be embodied in an 
ASIC, whidi would typically provide greater performance and cost efBciency in mass 
production, but would generally be more expensive to develop and less flexible) - the 
control program includes a measurement function 370 for acquiring the integrity 
30 metric from the computing platform and an authentication function 380 for 
authenticating a smart card (or other trusted component); 
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an interface 310 for connecting the trusted device 260 to the PCI bus for 
receiving information including image data (i.e. graphics primitives) from the CPU 
200 and also tmsted image data from the smaitcard 122, as will be described; 

frame buflfer memoiy 315, which comprises sufficient VRAM (video RAM) in 
S which to store at least one full image fi^e (a typical frame buffer memory 31S is 1-2 
Mbytes in size, for screen resolutions of 1280x768 supporting up to 16.7 million 
colours); 

a video DAC (digital to analogue conveiter) 320 for converting pixmap data 
into analogue signals for driving the (analogue) VDU 105, which connects to the 
10 video DAC 320 via a video interface 325; 

volatile memory 335, for example DRAM (dynamic RAM) or more expensive 
SRAM (static RAM), for storing state information, particularly received 
cryptographic keys, and for providing a work area for die microcontroller 300; 

a oyptogr^hic processor 340, comprisiDg hardware cryptographic 
15 accelerators and/or software, arranged to provide the trusted device 260 with a 
cryptogr^hic identity and to provide authenticity, integrity and confidentiality, guard 
against replay attacks, make digital signatures, and use digital certificates, as will be 
described in more detail below; and 

non-volatile memory 345, for example flash memory, for storing an identifier 
20 Idp of the trusted device 260 (for example a simple text string name - this can be used 
for indexing and labelling of data relevant to the trusted device, but is in itself 
insufficient to prove the identity of the platform under trusted conditions), a private 
key Sdp of the tmsted device 260, a certificate Certop signed and provided by a trusted 
third party certification agency (TP), such as VeriSign Inc., which binds the trusted 
25 device 260 with a signature publio^mvate key pair and a confidentiality public- 
private key pair and includes the CQrreq)onding public keys of the trusted device 260. 

A certificate typically contains such information, but not the public key of the CA. 
That public key is typically made available using a 'Public Key Infiastructure' (PKI). 
30 Operation of aPKI is well known to those skilled in the art of security. 



The certificate Cetlop is used to supply the public key of the trusted device 260 to 
third parties in such a way that third parties are confident of ihc source of tfie public 
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key and that the public key is a part of a valid public-private key pair. As such, it is 
unnecessary for a third party to have prior knowledge of, or to need to acquire, the 
public key of the trusted device 260. 

5 The certificate Tp (or, optionally, a further certificate) contains not only the public key 
of the trusted device 260 but also an authenticated value of the platform integrity 
metric measured by the trusted party (TP). In later communications sessions, a user 
of the platform 100 can verify (he integrity of the platform 100 by comparing the 
acquired integrity metric with the authentic integrity metric in the certificate. If there 
10 is a match, the user can be confident that die platform 10 has not been subverted. 
Knowledge of the TP*s generally*available public key enables simple verification of 
the certificate. 

The trusted device 260 is equipped with at least one method of reliably measuring or 
15 acquiring the integrity metric of the conq>uting platform 100 with which it is 
associated. In the present embodiment, the integrity metric is acquired by ttie 
measurement function 370 by generating a digest of the BIOS instructions in the 
BIOS memory. Such an acquired integrity metric, if verified as described above, 
gives a potential user of the platforaa 100 a higji level of confidence that the platform 
20 100 has not been subverted at a hardware, or BIOS program, level. Other known 
processes, for example virus checkers, will typically be in place to check that the 
operating system and s^lication program code has not been subverted. 

The measuremoit function 370 has access to: non-volatile memory 305,345 fiw 
25 storing a hash program 390 and a private key Sdp of the trusted device 260, and 
volatile memory 335 for storing acquired integrity metric in the form of a digest 361. 
In apptoptizte embodiments, the volatile memory 335 may also be used to store ttie 
public keys and associated ID labels 360a-360n of one or more authentic smart cards 
122 that can be used to gain access to the platfiirm 100. 

30 

In one preferred inq)lementation, as well as the digest, the integrity metric includes a 
Boolean vahie, ^ch is stored in volatile memory 335 by the measurement fimcti n 
370, for reasons that will become apparent 
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A preferred process for acquiring an integrity metric will now be described with 
reference to Figure 4. 

5 In step 500, at switch-on, the measurement function 370 monitors the activity of the 
main processor 200 on the PCI bus 225 to determine whether the trusted device 260 is 
the first memory accessed. Under conventional operation, a main processor would 
first be directed to the BIOS memoiy first in order to execute the BIOS progr am . 
However, in accordance with the arrangement shown, the main processor 200 is 

10 directed to the trusted device 260, which acts as a memory. In stq> 505, if the trusted 
device 260 is the first memoiy accessed, in step SIO, the measurement fimction 370 
writes to volatile memory 335 a Boolean value which indicates that the trusted device 
260 was the first memoiy accessed. Othowise, in step 5 15, the measurement fimction 
writes a Boolean value indiich indicates that the trusted device 260 was not the fiirst 

15 memory accessed. 

In the event the trusted device 260 is not the first memory accessed, there is of course 
a chance that the trusted device 260 will not be accessed at all. This would be the 
case, for example, if the main processor 200 were manipulated to run the BIOS 
20 program first Under these circumstances, the platform would operate, but would be 
unable to verify its integrity on demand, since the integrity metric would not be 
available. Further, if the trusted device 260 were accessed after the BIOS program 
had been accessed, tiie Boolean value would clearly indicate lack of integrity of the 
platform. 

25 

In step 520, ^en (or if) accessed as a memory by the main processor 200, the main 
processor 200 reads the stored native hash instructions 390 fiom the measurement 
function 370 in step 525* The bBsh instructions 390 are passed for processing by the 
main processor 200 over the data bus 22S. In step 530, main processor 200 executes 
30 the hash instructions 390 and uses them, in step 535, to compute a digest of the BIOS 
memory 215, by reading tfie contents of the BIOS monory 215 and processing those 
contents according to the ha^ program, in step 540, the main processor 200 writes 
the computed digest 361 to the appropri ate non-volatile memory location 335 in the 
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trusted device 260. The measurement function 370, in step 545, then calls the BIOS 
program in the BIOS memory 215, and execution continues in a conventional manner. 

Clearly, there are a number of different ways in which the integrity metric may be 
5 calculated, depending upon the scope of the trust required. The measiu^ient of the 
BIOS program*s integrity provides a fundamental check on the integrity of a 
platform's underlying processing environment The integrity metric should be of such 
a form that it will enable reasoning about the validity of the boot process * the value of 
the integrity metric can be used to verify i»4iether the platform booted using the 
10 correct BIOS. Optionally, individual functional blocks within the BIOS could have 
their own digest values, with an ensemble BIOS digest being a digest of these 
individual digests. This enables a policy to state which parts of BIOS operation are 
critical for an intended purpose, and which are irrelevant (in which case the individual 
digests must be stored in such a manner that validity of operation under the policy can 
15 be established). 

Other integrity checks could involve establishing that various other devices, 
components or s^aratus attached to the platform are present and in correct woridng 
order. In one exanq)le, the BIOS programs associated with a SCSI controller could be 

20 verified to ensure communications witii peripheral equipment could be trusted. In 
another example, the integrity of other devices, for example memory devices or co- 
processors, on the platfonn could be verified by enacting fixed challoige/response 
interactions to ensure consistent results. Where the trusted device 260 is a sq)arable 
component, some such form of interaction is desirable to provide an appropriate 

25 logical binding between the trusted device 260 and the platform. Also, althou^ in the 
present embodiment the trusted device 260 utilises the data bus as its main means of 
communication with ottier parts of the platform, it is feasible to provide alternative 
communications padis, such as hard-wired paths or optical paths - such an 
arrangement is described in greater detail below with reference to Figures 8 and 9. 

30 Further, altiiough in the present onbodiment iht trusted device 260 instructs the main 
processor 200 to calculate the integrity metric in other embodiments, the trusted 
device itself is arranged to measure one or more integrity metrics. 
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Preferably, the BIOS boot process includes mechanisms to verify the integrity of the 
boot process itself Such mechanisms are already known from, for example, bters 
draft "Wired for Management baseline specification v 2.0 - BOOT Integrity Service", 
and involve calculating digests of software or firmware before loading that software 

5 or firmware. Such a computed digest is compared with a value stored in a certificate 
provided by a trusted entity, whose public key is known to the BIOS. The 
software/firmware is then loaded only if the computed value matches the expected 
value from the certificate, and the certificate has been proven valid by use of tiie 
trusted entity's public key. Otherwise, an appropriate exception handling routine is 

10 invoked. 

Optionally, after receiving the con^>uted BIOS digest, the trusted device 260 may 
inspect the proper value of the BIOS digest in the certificate and not pass control to 
the BIOS if tfie computed digest does not match the proper value. Additionally, or 
IS alternatively, the trusted device 260 may inspect the Boolean value and not pass 
control back to the BIOS if the trusted device 260 was not the first memory accessed. 
In either of these cases, an appropriate exception handling routine may be invoked 

Figure 5 illustrates the flow of actions by a TP, the trusted device 260 incorporated 
20 into a platfomi, and a user (of a remote platform) who wants to verify the integrity of 
the trusted platform. It will be predated that substantially the same steps as are 
dq)icted in Figure S are involved when the oso- is a local user. In either case, the user 
would typically rely on some form of software application to enact the verificatiotL It 
would be possible to nm the software i^lication on the remote platform or the 
25 trusted platfinm. Howeva; ttim is a chance that, even on the ranote platform, the 
software s^Hcation could be subverted in some way. Therefore, it is anticipated that, 
for a hi^ level of integrity, the software application would reside on a smart card of 
the user, who would insot the smart card into an appropriate reader for the purposes 
of verification. Figure 5 illustrates the flow of actions for die general case - a more 
30 specific flow of actions for verification by a user smart card will be described with 
refsrence to Figure 6 further below. 
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At the first instance, a TP, which vouches for trusted platforms, will inspect the type 
of the platform to decide whether to vouch for it or not. This will be a matter of 
poUcy. If all is well, in step 600, the TP measures the value of integrity metric of the 
platform. Then, the TP generates a certificate, in step 60S, for the platfonn. The 
5 certificate is generated by the TP by ^^rpending the trusted device's public key, and 
optionally its ID label, to the measured integrity metric, and signing the string with 
the TP's private key. 

The trusted device 260 can subsequently prove its identity by using its private key to 
10 process some input data received firom the user and produce output data, such that the 
input/ou^ut pair is statistically impossible to produce without knowledge of the 
private key. Hence, knowledge of the private key forms the basis of identity in this 
case. Cleariy, it would be feasible to use synmietric encryption to form the basis of 
identity. However, the disadvantage of using symmetric encryptian is that the user 
15 would need to share his secret with the trusted device. Further, as a result of the need 
to share the secr^ with &e user, while symmetric encryption would in principle be 
sufficient to prove identity to the usot, it would insufficient to prove identity to a third 
party, who could not be entirely sure the verification originated from the trusted 
device or the user. 

20 

In step 610, the trusted device 260 is initialised by writing the certificate into the 
appropriate non-volatile memory locations of the trusted device 260. This is done, 
preferably, by secure communication with the trusted device 260 after it is installed in 
the motherboard 215. The method of writing the certificate to the trusted device 260 
25 is analogous to the method used to initialise smart cards by writing private keys 
thereto. The secure communications is siqjported by a ^master key', known only to 
the TP, that is written to die trusted device (or smart card) during manufacture, and 
used to enable the writing of data to the trusted device 260; writing of data to die 
trusted device 260 without knowledge of the master key is not possible. 

30 

At some later point during operati n of tfie platform, for example ^en it is switched 
on or reset, in step 615, the trusted device 260 acquires and stores th integrity metric 
of the platform. 
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When a user wishes to communicate with the platform, in step 620, he creates a 
nonce, such as a random number, and, in step 625, challenges the trusted device 260 
(the operating system of the platfoim, or an appropriate software application, is 
5 arranged to recognise the challenge and pass it to the trusted device 260, typically via 
a BIOS-type call, in an appropriate fashion). The nonce is used to protect the user 
from deception caused by replay of old but genuine signatures (called a 'replay 
attack*) by untrustworthy platforms. The process of providing a nonce and verifying 
the response is an example of the well-known 'challenge/response' process. 

10 

In step 630, the trusted device 260 receives the challenge and creates an app r o pr iate 
response. This may be a digest of ttie measured integrity metric and the nonce, and 
optionally its ID label. Then, in step 635, the trusted device 260 signs the digest, 
using its private key, and returns the signed digest, accompanied by the certificate 
IS Certop, to the user. 

In step 640, the user receives tfie challenge response and verifi^ the certificate using 
the well known public key of the TP. The user then, in step 650, extracts the trusted 
device's 260 public key fiom the certificate and uses it to decrypt the signed digest 

20 fipom the challenge response. Then, in step 660, the user verifies the nonce inside tfie 
challmge response. Next, in stq> 670, die user compares the computed integrity 
metric, which it extracts fitmi the challenge response, with tbc proper platform 
integrity metric, which it extracts fiom the certificate. If any of the foregoing 
verification steps fails, in steps 645, 655, 665 or 675, the whole process ends in step 

25 680 with ru) further cornmunicatioiis taking place. 

Assuming all is well, in steps 685 and 690, die usct and die trusted platform use other 
protocols to set iq> secure communications for odier data, where the data fiom the 
platform is preferably signed by the trusted device 260. 

30 

Further refimnots of this verification proces are possible. It is desirable that the 
diallenger becomes aware, throng the duUeoge, bodi of the value of die platform 
integrity metric and also of the method by which it was btained. Bodi these pieces of 
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information are desirable to allow the chaUenger to make a proper decision about the 
integrity of the platform. The challenger also has many different options available - it 
may accept that the integrity metric is recognised as valid in the trusted device 260, or 
may alternatively only accept that the platform has the relevant level of integrity if the 
5 value of the integrity metric is equal to a value held by the challenger (or may hold 
there to be different levels of trust in these two cases). 

The techniques of signing, using certificates, and challenge/response, and using them 
to prove idCTtity, are weU known to those skilled in the art of security and therefore 
10 need not be described in any more detail herein. 

In prefened arrangements of the system, a user employs a smart card 122 to verify a 
trusted platform. The processing engine of a smartcard suitable for use in accordance 
with the preferred embodiment is illustrated in Figure 7. The processing engine 

15 comprises a processor 400 for enacting standard encryption and decryption functions, 
to siqyport verification of information received fiom elsewhere. In the present 
embodiment, the processor 400 is an 8-bit microcontroller, which has a built-in 
opmting system and is arranged to communicate with the outside worid via 
asynchronous protocols specified through ISO 7816-3, 4, T=0, T=l and T=14 

20 standards. The smartcard also comprises non-volatile memory 420, for exan^le flash 
memory, containing an identifier Isc of the smartcard 122, a private key Ssc> used for 
digitally signing data, and a certificate Certsc> provided by a trusted diird party 
certification agency, which binds the smartcard witii public-private key pairs and 
includes the correqxmding public keys of the smartcard 1 22 (Ae same in nature to the 

25 certificate Certi^ of tfie trusted device 260). Further, the smaitcard contains 'seal' 
data SEAL in the non-volatile memory 420, which can be represented gr^hically by 
the trusted display processor 260 to indicate to die user that a process is operating 
securely widi the user's smartcard, as will be described in detail below. Inthepresent 
embodiment, the seal data SEAL is in the form of an image pixmap, which was 

30 originally selected by the user as a unique identifier, for example an image of the user 
himself and loaded into the smartcard 122 using well-known techniques. The 
processor 400 also has access to volatile memory 430, for example RAM, for storing 
state information (such as received keys) and providing a working area for the 
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processor 400, and an interface 440» for example electrical contacts, for 
communicating with a smart card reader. 

Seal images can constmie relatively large amounts of memory if stored as pixmaps. 
5 This may be a distinct disadvantage in circumstances where the image needs to be 
stored on a smartcard 122, where memory edacity is relatively limited. The memory 
requirement may be reduced by a number of different techniques. For example, the 
seal image could comprise: a compressed image, which can be decompressed by the 
trusted device 260; a thumb-nail image that forms the primitive element of a repeating 

10 mosaic generated by the trusted device 260; a naturally compressed image, such as a 
set of alphanumeric characters, which can be displayed by the trusted device 260 as a 
single large image, or used as a thumb-nail image as above. In any of these 
alternatives, the seal data itself may be in encrypted form and require the trusted 
device 260 to decrypt the data before it can be displayed. Alternatively, tfie seal data 

15 may be an encrypted index, which identifies one of a numbo: of possible images 
stored by &e host computer 100 or a network server. In this case, the index would be 
fetched by the tnisted device 260 across a secure channel and decrypted in order to 
retrieve and display the correct image. Further, the seal data could conqmse 
instructions (for example PostScript™ instructions) that could be interpreted by an 

20 qipropriately programmed tnisted device 260 to generate an image. 

As indicated above. Figure 6 shows the flow of actions in an example of verification 
of platform integrity by a user interacting with the trusted platform with a smart card 
122. As will be described, the process conveniently inq>lements a challenge/response 

25 routine* There exist many available challenge^esponse mechanisms. The 
implonentation of an authentication protocol used in the presmt embodiment is 
nnitual (or 3-stq>) authoitication, as described in ISO/IEC 9798-3, ^Information 
tedmology - Security tedmiques - Entity authentication mechanisms; Part 3; Entity 
authentication using a public key algorithm**. International Organization for 

30 Standardization, November 12293. Of course, there is no reason why otho* 
authentication procedures cazmot be used, for example 2-step or 4-stq[>, as also 
described in this reference. 
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Initially, the user inserts their smart card 122 into the smart card reader 120 of the 
platform in step 700. 

Beforehand, a platform configured for use by users of in this way will typically be 
5 operating under the control of its standard operating system and executing the 
authentication process, which waits for a user to insert their smart card 122. Apart 
torn the smart card reader 120 being active in this way, such a platform is typically 
rendered inaccessible to users by 'locking' the user interface (i.e. the screen, keyboard 
and mouse). 

10 

When the smart card 122 is inserted into the smart card reader 120, the trusted device 
260 is triggered to attempt mutual authentication in step by generating and 
transmitting a nonce A to the smart card 122 in step 70S. A nonce, such as a random 
number, is used to protect the originator from deception caused by replay of old but 
1 5 genmne responses (called a 'replay attack') by untrustworthy third parties. 

In response, in step 710, the smart card 122 generates and returns a response 
conq)rising the concatenation of: fhe plain text of the nonce A, a new nonce B 
generated by the smart card 122, an ID of the trusted device 260 and some 
20 redundancy, the signature of the plain text, generated by signing the plain text with 
the private key of the smart card 122; and a certificate containing the ID and the 
public key of the smart card 122. 

The trusted device 260 authenticates the response by using the public key in the 
25 certificate to verify the signature of the plain text in step 71S. If the response is not 
authentic, Ihe process ends in step 720. If the response is authentic, in step 725 the 
trusted device 260 generates and sends a fiirther response including the concatenation 
of: the plain text of the nonce A» the nonce B, an ID of the smart card 122 and the 
acquired integrity metric; the signature of the plain text, gen^ated by signing the 
30 plain text using the private key of the trusted device 260; and tiie certificate 
comprising the public key of the trusted device 260 and the authentic integrity metric, 
both signed by the private key of the TP. 
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The smart card 122 authenticates this response by using the public key of the TP and 
comparing the acquired integrity metric with the authentic integrity metric, where a 
match indicates successfiil verification, in step 730. If the further response is not 
authentic, the process ends in step 735. 

5 

If the procedure is successful, both the trusted device 260 has authenticated the smart 
card 122 and the smart card 122 has verified the integrity of the trusted platform and, 
in step 740, the authentication process executes the secure process for the user. 

10 In certain types of interaction, the authentication process can end at this point 
However, if a session is to be continued between the user and the trusted platform, it 
is desirable to ensure that the user remains authenticated to the platform. 

Where continued authentication is required, the authentication process sets an interval 
15 timer in step 745. Thereafter, using appropriate operating system intemq)t routines, 
the authoitication process senaces the interv^al timer periodically to detect ^en the 
timer meets or exceeds a pre-determined timeoutperiod in step 750. 

Clearly, the authentication process and the interval timer run in parallel with the 
20 secure process. When the timeout period is met or exceeded, the authentication 
process triggers the trusted device 260 to re-authenticate the smart card 122, by 
transmitting a diallenge for the smart card 122 to identify itself in stq> 760. Hie 
smart card 122 returns a certificate including its ID and its public key in step 765. In 
step 770, if there is no response (for example, as a result of the smart card 122 having 
25 been ronoved) or the certificate is no longer valid for some reason (for example, the 
smart card has been replaced with a different smart card), the session is terminated by 
the trusted device 260 in 8tq> 775. Otherwise, in step 770, the process from step 745 
r^eats by resetting the interval timer 

30 Additionally, or alternatively, in some embodiments it may be required that the user 
profile is encrypted and signed to protect privacy and integrity. If so, a secure data 
transfer protocol m^ be needed between the trusted device 260 and the smart card 
122. There exist many available mechanisms f r transfening secure credentials 
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between two entities. A possible implementation, which may be used in the present 
embodiment, is secure key transport mechanisms from ISO/DEC DIS 11770-3, 
*Tnforraation technology - Security techniques - Key management - Part 3: 
Mechanisms using asymmetric techniques", International Organization for 
5 Standardization, March 1997. 

Modifications of this verification process using other well-known challenge and 
response techniques can easily be achieved by the skilled person. Similarly, 
alternative verification processes can be used by parties interacting with the platform 
10 in a different manner (that is, other than as a user equipped with a smart card). 

As described above, the trusted device 260 lends its identity and trusted processes to 
the host computer and the trusted display processor has those properties by virtue of 
its tamper-resistance, resistance to forgery, and resistance to counterfeiting. Only 
15 selected entities with appropriate authentication mechanisms are able to influaice the 
processes running inside the trusted device 260. Neither an ordinary user of the host 
computer, nor any ordinary user or any ordinary entity connected via a network to the 
host computer may access or intofisre with the processes running inside the trusted 
device 260. The trusted device 260 has the property of being "inviolate", 

20 

ft will be apparent fiom Figure 3 that the frame buffer memory 3 1 5 is only accessible 
by the trusted display processor 260 itself and not by the CPU 200. This is an 
important feature of the preferred embodiment, since it is imperative that the CPU 
200, or, more inq>ortantly, subversive ^implication programs or viruses, cannot modify 
25 the pixmq) during a trusted operation. Of course, it would be feasible to provide die 
same level of security even if the CPU 200 could directly access the frame buffer 
memory 315, as long as the trusted display processor 260 were arranged to have 
ultimate control ovec when the CPU 200 could access the frame buffer memory 315. 
Obviously, this latter scheme would be more difSctilt to implement 

30 

A typical process by whidi gr^hics primitives are genaated by a host computer 1 00 
will now be described by way of background. Initially, an application program, v/idOx 
wishes to display a particular image, makes an appropriate call, via a graphical API 
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(plication programming interface), to the operating system. An API typically 
provides a standard interface for an application program to access specific underlying 
display functions, such as provided by Windows NT™, for the purposes of displaying 
an image. The API call causes the operating system to make respective gr^hics 
5 driver library routine calls, which result in the generation of graphics primitives 
specific to a display processor, which in this case is the trusted display processor 260. 
These graphics primitives are finally passed by the CPU 200 to the trusted display 
processor 260. Example graphics primitives might be 'draw a line from point x to 
point y with thickness z' or 'fill an area bounded by points w, x, y and z with a colour 
10 a\ 

The control program of the microcontroller 300 controls the microcontroller to 
provide the standard display fimctions to process the received graphics primitives, 
specifically: 

15 receiving fiom the CPU 200 and processing gr^hics primitives to form 

pixmsq) data which is directly rq^resentative of an image to be displayed on Hie VDU 
105 screen, where the pixmap data generally include intmsity values for each of the 
red, green and bhie dots of each addressable pixel on the VDU 105 screen; 
storing the pixmap data into the fiame buffer memory 3 1 5; and 

20 periodically, for example sixty times a second, reading the pixmap data from the 
frame bufifo* memory 315, converting the data into analogue signals using the video 
DAC and transmitting Hxe analogue signals to the VDU 105 to display the required 
image on the s cr een. 

25 Apart from the standard display functions, the control program includes a function to 
mix display image data deceived fiom the CPU 200 with trusted image data to form a 
single pixmap. The control program also manages interaction with the cryptogrq>hic 
processor. 

30 The trusted display processor 260 forms a part of the overall 'display system' of the 
host conq>uter 100; the other parts typically being display functions of the operating 
system, ^ch can be 'called* by application pr ogr am s and i^ch access the standard 
di^lay functions of the gr^hics processor, and &e VDU 105. In other words, die 
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'display system' of a host computer 100 comprises every piece of hardware or 
functionality which is concerned with displaying an image. 

A specific embodiment of the invention will now be described, with reference to 
5 Figures 8 to 10. Other secure tokens (handheld PC, or other item capable of being 
held personally by a user) can be used, though for convenience only smart cards are 
discussed here. The trusted computing platform described is a personal computer, 
but any platform c£q>able of the requisite functionality can be used. 

10 Figure 8 illustrates the physical system. Trtisted platform 800 has the elements of 
trusted platfonn 100 described in Figure 1 (and below). Only elements of specific 
relevance to the present invention are shown in Figure 8. The system according to 
the invention has certain additional elements, as are described below. 

1 S The trusted componrat (TQ 803 is in the path between nomial conq)uter CPU 804 
and the display 801 . This enables the TC 1 03 to write reliably to the display, without 
fear of subversion fiom normal software, including the operating system is the name 
described with refermce to Figure 1 to 7. The host conq)uter is connected to a 
keyboard 80S that has a built-m smart card reader 808. A smart card (SC) 806 is 

20 plugged into the keyboard and can be accessed by the host CPU 804 and the TC 803. 
The smart card 806 is able to communicate securely with die TC 803. The biometric 
reader (BR 807 is connected to the keyboard and can be accessed by the host CPU 
804 and the TC 803. The biometric reader may in alternative arrangements be 
incorporated physically into the smart card reader 808 or the smart card 806 or 

25 connected in some other way to the host CPU 804. 

The specific form of biometric reader to be used is not relevant to the invention, and 
will not be discussed in detail here. The biometric reader 808 must be capable of 
measuring a parameter individual to a user, and providing data which will allow the 
30 user to be identified, generally by matching against eariierrecorded data measured for 
the sam user. Alternatives already known are fingerprint readers, iris pattern 
detectors, signature readers, voice print detectors, and many others - the present 
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invention can employ any of the above. 

In the embodiment described, the smart card 806 has a cryptographic identity (as 
shown in Figure 7). It is preferred also (though again not essential in all 
5 embodiments) that the biometric reader 807 has, in addition to its biometric 
functionality, the functionality of a secure token as shown in Figure 7 - that is, a 
cryptographic identity, functionality to allow it to authenticate a trusted platform or 
secure token, and each cryptogr^hic functionality as needed to allow secure 
communication with another system element 

10 

Figure 9 illustrates diagrammatically the transaction between TC, SC and BR. Upon 
sign-on using the smart card 806, there is mutual authentication between the TC 803 
and the smart card 901, 902 and certificates are exchanged, optionally with the smart 
card checking that the integrity of the TC is satisfactory before proceeding further 

15 908. The TC stores a unique identity for the smart card, which is preferably the 
certificate of the smart card public (verification) key. A bio code 1016 is transferred 
ftom SC to TC 903 encrypted with a symmetric session key set up for this purpose. 
Optionally, comparison software is also sent firom the SC to the TC 9 1 0. Optionally, 
the TC authenticates to the BR and/or BR authenticates to TC [904, 905] and 

20 certificates are exchanged Optionally, this can be combined with an integrity check 
by the TC on the BR 909 or vice versa. The biometric data is then sent fiom BR to 
TC, encrypted with a synmietric session key set up for this purpose 906. The TC 
then compares the biometric data with the bio code, using trusted biometric 
comparison software 1011.. Optionally, the TC sends the SC the result of the 

25 biometric match, signed using the TC's private signing key 907. Optionally, the TC 
or the SC take a metering record of the transaction 1014, 1015. 

Steps of authentication are essentially as shown above with reference to Figures 5 
and 6. Communication using a syomietric key is well-known in the cryptogr^hic 
30 art, and does not need to be described further here 

Figure 10 is a 1 gical diagram of TC 803, SC 806 and BR 807, A certification 
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authority (CA) issues certificates corresponding to public and private key pairs 
associated with the TC and SC 1005, 1006, 1007 and possibly the BR 1008. Each 
end user has a smart card 806 equipped with an RSA key pair for signature and 
verification 1003. The trusted component has two RSA key pairs respectively for 

5 signature-verification and encryption-decryption 1001, 1002. The BRneed not, in all 
embodiments, be trustworthy or secure (although this is preferable). In the 
arrangement preferred, it does not itself implement the biometric algorithm but only 
reads &e biometric data from the user. The reader is created by a trusted entity and 
this means it has been given a public/private key pair 1004 supported by a CA's 

10 certificate. As indicated above, the biometric reader can be of any kind (for example 
iris recognition, retina, or voice). 

A preferred protocol for this procedure is described below. In the protocol the 
following notation will be used:- 

• Nn-x- a nonce issued by the entity X(X« {SC,TC} with a number n; 

• Dn - a data element, containing some extra information that may need 
to be transmitted in a real q>plication; such data elonents are included 
for generality, and the value may be null; 

• SK - a session key used for protecting transmission of Bio data (BD) 
(for example, fingerprint data) and Bio code (BC). This session key 
is a shared key for symmetric encryption-decryption, eg DBS. 

• ml, m2 * a concatenation of two data elements ml and m2; 

• Sx (m) - a signature on a data element m signed with a private 
signature key of tiie entity X (X = {SC, TC) ; 

• Ex (m) " a data element m encrypted via an asymmetric algorithm by 
using the public encryption key of the entity X (X = {TC}); 

• E ^m) - a data element m encrypted via a symmetric algorithm by 
using the key K; 

• A B:m - a data element m is transferred ftom entity A (A = {SC, 
TC} to entity B (B = {SC, TC}); 

• Cert (X, Y) - a certificate of the entity X's public key issued by the 
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CA for the purpose Y. where X = {SC, TC} and Y = {V, E} (V - 
verification and E - encryption). 

A preferred protocol that allows the SC and TC to work together to authenticate the 
5 user is as follows (stages A - D): 

A) Mutual authentication between SC and TC and transfer of bio code from 
SC toTC 

SC-^TC: Ni-sc Di 
10 TC SC: N2-TC, Cert (TC,V), Cert (TC, E), D2, Stc (Ni^, Nltc, SC, D3) 

SC TC: Etc (SKI), Cert (SC, V), D4, Eski (Ni-sc N2-TC, BC, Ds), Ssc (Ni^ N2- 
tcTCEtc (SK1),D6) 

The TC implements the biometric algorithm and compares the bio Data with the bio 
15 Code. Li order to trust that this infoniiation is actuaUy correct fitnn the tnie source 
and not a result of an impostor's attack, the data must be sent fit)m the SC and the 
BR in a secure way. The SC and TC should mutually authenticate each other at the 
beginning of a session. The bio code also must be transferred fiom the SC to the TC. 
This will reduce the number of transfers between SC and TC. The bio code will be 
20 discarded Smm the TC at the end of a scssiorL The cipher used for encryption does 
not need to be specified (one possibility is use of CBC mode to take advantage of the 
random (nonce provision). 

B) Mataal authentication between BR and TC and establishment of a session 
25 key (optional) 

BR-^TC:N«R, D7 

TC -H. BR: N4.TC Cert (TC, V), Cert (TC, E), Ds. Stc QiysK N4-tc. BR, D9) 
BR — TC: Etc(SK2), Cert (BR, V), Dio. Sbr. (N>bic N4-tc, TC, Etc(SK2), Dn) 

30 The TC and BR shall authenticate each other. It is desirable for the TC to 
authenticate the BR, particularly if the BR is trusted and it can prove that user data is 
held securely - the TC can Acn ensure that bi data will not be collected and 
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transferred to an illegitimate user or purpose. Authentication of the TC by the BR 
prevents transfer of data from the BR to an illegitimate TC. It is strongly desirable 
for the TC to be able to tell the user that the BR is a valid one, so he or she can put 
his finger on it or allow other biometric information to be taken with security. A 
S reason for authenticating the BR (and not assuming that a specific BR will be 
attached on the PC) is because of the nature of distributed environments. It may be 
desirable that the BR and the user are not physically co-located with TC (eg public 
client platforms at airports). 

10 The solution described above for this stage is strong authentication, which is one 
solution for integrity checking between the TC and BR (others are possible, including 
the TC checking out the integrity of the BR, or vice versa in an analogous way to the 
SC checking the integrity of the TC, or vice versa); a weaker approach can be used in 
some cases such as asking for another type of identity. For example, this stage of 

1 S mutual authentication may not be necessary if an integrity check is included within 
the trusted computing platform and the BR is part of the trusted computing platform; 
mutual authentication is much more important for "^lug-in** biometric readers. 

If this stage is not carried out, the establishment of a key is to be used for encryption 
20 of the biometric data needs to be incorporated into the protocol shown for the 
following stage, ie where the biometric data is set fixmi BR to TC. 

Q Biometric data is sent from BR to TC 

TC BR: N5-TC.D12 
25 BR TC: Nmr. Dix Esia (Ns-tc, N«r, BR, TC, BD. Du) 

A PC initialises an au&enticadon request by sending a message to the user, which 
then uses the biometric reader. The BR collects the biometric data (BD) and sends it 
to the TC then the TC does the comparison resulting to a match or not. The 
30 Biometric data is sent encrypted with the session key SK2 set up previously. 

D) TC sends SC the resalt of the biometric match (optional) 
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SC — TC: N7^c, Di5 

TC SC: Stc (N7-SC. SC. inatch_resulUDi6), Di? 



One way authentication is included within this stage. The result of the match is 
3 displayed on the screen or if required is conununicated by the TC to the smart card 
infonning it of the correct identification. match_result could be a simple a£Snnative 
or negative, or something more complex indicating how closely the biometric data 
and stored template match 

1 0 The skilled man will appreciate that many variations on the above are possible. For 
example, if the smart card is combined together with the biometric reader, a 
simplified protocol can be employed. Another possibility is for the biometric data for 
matching to be held remotely under control of another trusted platfonn, to be 
accessed by a secure information exchange between the two trusted platforms. These 

IS and other 2q[>proaches will be recognised as fiilly compatible with the invention as 
here described and claimed. 
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CLAIMS 

1 . A computing platform adspied to authenticate a user, comprising: 

a trusted component having a secure processor protected from physical 
S and logical interference; 

communication paths between the trusted component and firstly, a 
biometiic reader adapted to capture biometric data from a user and having a 
reader identifier and, secondly, a secure token for storing authentic biometric 
data of a user and having a token identifier, 
1 0 wherein the secure processor is adqsted to authenticate the biometric reader and 

the secure token by their respective identifiers, retrieve authentic biometric data from 
the secure tokoi, retrieve captured biometric data from the biometric reader, and 
compare the audientic biometric data and the captured biometric data to authenticate 
a user. 

15 

2. A computing platform as claimed in claim 1 , wherein the trusted component is 
ad^ted to check the integrity of code used by the secure processor but stored outside 
the trusted component 

20 3. A computing platform as claimed in claim 1 or claim 2, wherein the trusted 
component is adapted to check the integrity of code or processors accessed by the 
communication paths. 

4. A conq)uting platform as claimed in any preceding claim, wherein the trusted 
25 component has a cryptographic identity. 

5. A biometric reader adapted to cq)ture biometric data from a user and 
comprising a reader identifier, wherein the biometric reader has a cryptogr^hic 
identity and a cryptographic processor. 

30 



SUBSTITUTE SHEET (RULE 26) 



WO01/2r723 



PCT/GB00y03850 



32 

6. A data processing system comprising a computing platform as claimed in claim 
4 and a biometric reader as claimed in claim S, wherein the trusted component and 
the biometric reader are adapted for mutual authentication. 

5 7. A data processing system as claimed in claim 6, wherein data is communicated 
securely between the biometric reader and the tnisted component under a session key. 

8. A secure token for retaining authentic user biometric data, comprising: 

a memory holding the authentic user biometric data; and 
10 a token identifier. 

9. A secure token as claimed in claim 8, wherein the secure token is a smart card. 

10. A secure token as claimed in claim 8 or 9, wherem the secure token has a 
15 ciyptographic identity. 

11. A data processing system comprising a computing platform as claimed in claim 
4 and a secure token as claimed in claim 9, wherein the secure token and the trusted 
component are adapted for mutual authentication. 

20 

12. A data processing system as claimed in claim 11, wherein data is 
communicated securely between the secure token and the trusted component under a 
session key. 

25 13. A data processing system as claimed in claim 12, adapted such that code for 
comparing biom^c data is held on the secure token, downloaded to the trusted 
conq>onait for comparing biometric data^ and is deleted after comparison. 

14. A data processing system as claimed in any of claims 11 to 13, wherein a 
30 comparison of biometric data is cryptographically signed by the trusted component 
and provided to the secure token. 
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15. A data processing system as claimed in any of claims 11 to 14 and further 
comprising a biometric reader as claimed in claim 5. 



16. A method of authenticating a user by a coiiq)uting platfonm containing a trusted 
5 component having a secure processor protected from physical and logical 

interference, the method comprising: 

the secure processor authenticating a biometric reader; 
the secure processor authenticating a secure token containing authentic 
user biometric data; 

1 0 c^ture of user biometric data by the biometric reader, and transfer of the 

captured user biometric data to the secure processor, 

transfer of the authentic user biometric data to the secure processor, 
comparison of the authentic user biometric data with the c^tured user 

biometric data; and 

15 authentication of the user by the secure processor on the basis of the 

biometric data comparison. 

17. A method as claimed in claim 16, wherein the trusted component and the 
secure token each have a cryptographic identity, and the secure token also 

20 authenticates the trusted component 

18. A method as claimed in claim 16orclaim 17, wherein the biometric reader and 
the triisted component each have a cryptographic identity, and the biometric reader 
also authenticates the trusted component 

25 

19. A method as claimed in claim 17 or claim 18, wherein the trusted component 
communicates securely with the secure token and/or the biometric reader under a 
session key. 



SUBSTITUTE SHEET (RULE 26) 



wo 01/27723 



PCT/GBOO/03850 




wo 01/2T723 



PCT/GBOO/03850 



2/8 



VRAM 



^-315 



CRYPTO 
PROC 



M V 




MICRO- 
CONTROLLER 



340 



A — ^ 



A — ^ 



^< — }f 



CONTROL 

PROGRAM 

-1 1 — 

' _ ■ 



Idp Sdp CERTqp 



STATE 



VDAC 



■320 



'305 
-390 

345 
'380 



--335 



330 



/ 



325 

Fig.S 




Fig. 7 



SUBSTITUTE SHEET (RULE 26) 



wo 01/27723 



PCT/GBOO/03850 



3/8 



500 



505 



SWITCH-ON 




NO 



510 



YES 



WRITE POSITIVE 
BOOLEAN VALUE 



525 



READ HASH 
INSTRUCTIONS 



530 



DIRECT CPU TO 
EXECUTE HASH 
INSTRUCTIONS 



WRITE NEGATIVE 
BOOLEAN VALUE 




T 

515 



YES 



COMPUTE DIGEST 



— 535 



WRITE DIGEST 
DEVICE MEMORY 



5^0 



Fig. 4 



DIRECT CONTROL 
TO BIOS 



545 



SUBSTITUTE SHEET (RULE 26) 



wo 01/27723 



PCT/GB0O/O38SO 



4/8 



TRUSTED DEVICE 



TRUSTED PARTY 



630^ 



61^ 



ACQUIRE 
INTEGRITY METRIC 



RECEIVE 
CHALLENGE & 
GENERATE DIGEST 



A 



SIGN & RETURN 
DIGEST 



635 



690 

4- 



ESTABUSH 
SECURE 
COMMUNICATIONS 



A 



600 



605 



610 



MEASURE 
INTEGRITY 
METRIC 

~~r- 



GENERATE 
CERTIFICATE 



WRITE 
CERTIFICATE 
TO DEVICE 



CHALLENGE 



RESPONSE 



680-v 



USER 



620 

GENERATE NONCE | 



625 



TRANSMIT 
CHALLENGE 



6A0 



RECEIVE RESPONSE & 
VERIFY CERTIFICATE 



NO 




,0K7 



6^5 
650 



EXTRACT PUBUC 
KEY & DECRYPT 
DIGEST 



NO 




655 
660 



VERIFY NONCE 



NO 



665 
670 



COMPARE METRICS 



NO X\/675 



Fig 5 




K ESTABUSH 
) SECURE 
IX COMMUNICATIONS 



SUBSTITUTE SHEET (RULE 26) 



wo 01/27723 PCr/GBOO/03850 



5/8 



TRUSTED DEVICE 



AUTHENTICATION/ 
SECURE PROCESS 



LOGON SMART CARD 



705 



INSERT LOGON 




SMART CARD 


/710 


♦ 




TRANSMIT 




RETURN 


NONCE 




RESPONSE 




SET INTERVAL 
TIMER 



-7^5 



760 




765 



CHALLENGE LOGON 




RETURN 


SMARTCARD 




CERTinCATE 




Fig 6 



SUBSTITUTE SHEET (RULE 26) 



wo 01/27723 PCT/GB0O/Q3850 




SUBSTITUTE SHEET (RULE 26) 



wo 01/27723 



PCT/GB00/038S0 




SUBSTITUTE SHEET (RULE 26) 



wo 01/27723 



PCT/GBOO/03850 




SUBSTITUTE SHEET (RULE 26) 



INTERNATIONAL SEARCH REPORT 



Intcmot : AppHcattonNo 

PCT/GB 00/03850 



A. CLASSIFIC AHON OF SUBJECT MATTER , 

IPC 7 G06F1/00 G07C9/00 



Aoconfinq to International Pateni Classiflcatkyr (IPC) Of lo boOi naltonai ctasstficatton and tPC 



& FIELDS SEARCHED 



Mitimun documantation searched (dasstflcaiion system t d ow o d by dassificaiion symtoofa) 

IPC 7 G06F G07C G07F 



OocunomatiansaarctM other man nMnMondocumeiwtlon to ito Men mat In the fiekto aeantiad 



Eleemniedau baas oonaulled dining the intefnatlonalsearel) (name at data bass ana where practical ssareli terns usad) 

EPO-Internal , WPI Data, PAJ 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* CttaMon ot docume n t. wtti inacaMon. wtisfe appropdats. ottlte lelsvant passages 



RslannttociainiNa 



US 4 993 068 A (PIOSENKA GERALD V 
12 February 1991 (1991-02-12) 
abstract; figures 1,2 
column 8, line 10 - last line 

UO 96 36934 A (SMART TOUCH LLC) 
21 November 1996 (1996-11-21) 
page 8, line 30 -page 11, line 7 
page 123, line 1 - line 33 



ET AL) 



UO 98 55912 A (SPYRUS INC) 
10 December 1998 (1998-12-10) 
page 9, line 2 -page 10, line 21 
page 12, line 30 -page 13, line 10 
page 18, line 17 -page 21, line 9 
page 30, line 9 -page 31, line 16 
page 32, line 8 -page 34, line 31 
page 39, line 22 -page 40, line 18 



1-12, 
15-19 



1-12, 
15-19 



1-5,10, 
16-19 



-/- 



m 



Further doainantsm listed hi the oondnuatton of booi C 



|){ I Pitentfkmly members are Usiad In 



* Spaeu categories off cfied documents : 

* A* document defining the gsneral state of the aft wMch Is not 

oonsMamd to tie off peitlcuig filwKe 
*E* etfterdocumembutpubfbhedonoraflerths Ir ue n ia flo nel 
HkiQdiffa 

V document vMchfflsythfOwdouMi on prtotty dakn(s)or 
wWrt tictedtoestat< tf>piep util cttlonjMe 
dttfon or other spedal reason (as t pec W ec^ 

XT document raferring to an oral d]adaeure,uset. exhUtonor 



T later dooimenlpubiahed aBgttw Inte rna ti o na l Mrtg d rte 
or prtarty date and not k) confHct Mrtih the appQcatkxi tiut 
cflod to understand the pilndpte or tl>eory underfykig the 



"P" (tocumeMputMed prior to the Menodonid tOngdHebui 
taler than the prtorlfydatectafcned 



*X* document off partlcutarrelevsnoe; the ctalmBd invention 
cannot be oonMerednowel or cannot be oonstdered to 
kivolve an mventkresiepwtMn the document li taken alone 

"Y* document of paftlculBr relevance; the dafened invenikMi 
cannot be oonaidared to invoiMi an InventiHe step wtien the 
documertt ii combined with one or more oltier such doo^ 
menis, such oomtjlnatton beftig obvloua to a parson sUied 
ki the art 

'V document membar off the same patent ftmiy 



Dale off the ec&Ml oompteOon off the Memaitonal eeeftfi 



29 January 2001 



OMe off matag of the Memailanal 



02/02/2001 



Name and maSng adtas off the 6A 

European Paleni Omoe, PA 5518 Paientlaan 2 
NL-22aOHVR9s«9c 
Tel (+31-70) 340-2040. Tk. 31 6S1 epo nt. 
Fax (431-70) 340-3016 



Auihortzed oKloar 



Powell. D 



FdoR PCT/tSMIO (Moond Ml) iiuV tefiS) 



page 1 of 2 



INTERNATIONAL SEARCH REPORT ^^^^ 

PCT/GB 00/03850 


C^ContlniiaUon) DOCUMENTS CONSIDERED TO BE RELEVANT 


Category* 


Citation of documeni. with indtcatton.where appropfiate. of the relevant passages 


Relevant to daim No. 


P.A 
A 


UO 00 00882 A (LCI SMARTPEN NV) 
6 January 2000 (2000-01-06) 
the whole document 

US 5 473 692 A (DAVIS DEREK L) 
5 December 1995 (1995-12-05) 


1,16 



Poon PCT/iaV2l0 (otfitinutfivt at Mond iriMt) (July 1903) 



page 2 of 2 



INTERNATIONAL SEARCH REPORT 

InturmjOon on pmmnt tvnUy arnnbwM 



; AppUeadon No 

PCT/GB 00/03850 



Patent document 




Pubtication 




Patent family 




Putillcatlon 


dted tn search report 




data 




member(8) 




data 


US 4993068 


A 


12-02-1991 


NONE 






UO 9636934 


A 


21-11-1996 


US 


5613012 


A 








AU 


5922696 


A 

A 










BR 


9608580 


A 


05-01-1999 








CA 


2221321 


A 


Zl-11-1990 








CN 


1191027 


A 

A 


19-08-1998 








EP 


0912959 


A 

A 


UO— UD— i2T2f5f 








JP 


11511882 


T 


12-10-1999 








US 


6012039 


A 


04-01-2000 








US 


5838812 


A 


17-11-1998 








US 


5870723 


A 


09-02-1999 








US 


5764789 


A 


09-06-1998 








US 


5802199 


A 


01-09-1998 








US 


5805719 


A 


08-09-1998 



WO 9855912 


A 


10-12-1998 


US 


6003135 A 


14-12-1999 






AU 


7709498 A 


21-12-1998 


WO 0000882 


A 


06-01-2000 


AU 


5206499 A 


17-01-2000 


US 5473692 


A 


05-12-1995 


AU 


3583295 A 


27-03-1996 






EP 


0780039 A 


25-06-1997 








JP 


10507324 T 


14-07-1998 








UO 


9608092 A 


14-03-1996 








US 


5568552 A 


22-10-1996 



THIS PAGE BLANBC(usFTO) 



